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DETAILED ACTION 



This Office Action is responsive to Applicants amendment (Paper No. 1 1 ) of 
application 09/183,335 filed October 30, 1998. The amendment filed December 26, 
2002 amended several claims but canceled none of them. Accordingly Claims 1-29 are 
presented for examination on their merits. 



1 . Applicants amendments filed on December 26, 2002 have been fully considered, 
but the Applicants arguments are not found to be persuasive, although the prior 101 
rejection has been overcome by the current amendment and is withdrawn. However the 
amendment caused new references to be found regarding the technology arts. 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 1 02 of this title, if the differences between the 
subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made 
to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was 



Rejection, 35 U.S.C. 103(a) 

3. Claims 1-5, 17-20, and 22-29 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Gottesman et al (US 6,049,782 A) (hereinafter "Gottesman") and 
Petroutsos (Mastering Visual Basic 5) (hereinafter Petroutsos), and further in view of 
Carter (US 5,878,400 A) (hereinafter Carter) and Foster (US 6,052,672 A) (hereinafter 
Foster) and Doktor (US 5,604,899) (hereinafter Doktor). 



Response To Arguments 



made. 
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As to Claim 1 Gottesman discloses directly or inherently (see at least cols 1-14, 
but particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1- 
16) all of the steps in amended claim 1, both as an inventive concept and as computer 
program functions and steps to be performed, either implicitly or explicitly. He teaches 
the creation and use of price tables and tier/pricing (product) rules for both products 
and sub-products linked to financial transactions, and rules linked to price tables, 
identifying the correct rule for the transaction, and pricing the transaction according to 
the tier/pricing (product) rules. All of the claimed steps are also inherent in what 
Gottesman teaches. But he does not specifically teach the detailed programmatic steps 
for these software logic functions. 

Carter discloses (see at least columns 1-26 but in particular colums 1-8) claims 
1-29 regarding pricing (product) rules and pricing tables. 

Foster discloses (see at least columns 1-16 but in particular columns 1-9) claims 
1-29 regarding mapping production services (product rules) and price tables. 

Petroutsos teaches (see his book in general, but particularly Chapter 3 at least 
the sections "Arrays" through "Arrays of Arrays", and "If.. Then. ..End", and Chapter 11 
at least the sections "Databases and Database Management Systems" through "The 
Data Control's Properties"), by example of one of several computer programming 
languages then available, how relatively logical, simple, and obvious it would have been 
for one skilled in the art at the time of the invention to create all the programming steps 
necessary to translate an inventive concept, like Gottesman's described computer logic 
functions to be performed, into a working computer software program. For such skilled 
programmers it would have been obvious in a financial transaction system containing 
price tables and product (component) rules for multiple products (components) and 
multiple prices to develop the computer logic and the means for the entering of specific 
pricing and other calculations required in the tables and to employ specific names, 
identifiers, and references for the pricing and product (component) databases (tables) 
and their data fields, together with the programmatic means to both create all of the 
logic and tables and to link and associate them all together for the purpose and function 
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intended to be performed, including display only information. It is inherent in such 
programs to always have both mandatory and optional attributes in their tables and 
rules, and to assign status and a name to each of them. For example a table or field 
identifier is mandatory in order for the program to function properly, yet the number and 
type of fields and the individual rule descriptions and logic are discretionary. It would 
also be obvious to allow for the temporary disuse of one or more of those rules as an 
optional attribute, for a variety of operational reasons: possible temporary 
discontinuance of the product as one example, or a change in the attributes of the 
product itself as another reason. 

Doktor discloses claims 1-29 (see at least columns 1-36 but in particular 
columns1-10) regarding the design and implementation of databases containing 
product rules and pricing tables. 

In view of Gottesmans' teaching, it would have been obvious to one skilled in the 
art at the time of the invention to integrate Gottesmans 1 invention with the teachings of 
Petroutsos and Carter and Foster and Doktor because their combination would have 
been common sense and advantageous and have provided a completed, more 
effecient, and operational financial transaction system that could have been beneficially 
used by financial service companies to save money and increase profitability. Likewise, 
in light of the teachings of Petroutsos Carter, Foster, and Doktor, it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Petroutsos and Carter and Foster and Doktor with those of Gottesman for the same 
reason. 

As to Claim 2 Gottesman discloses (see at least cols 1-14, but particularly col 4, lines 
42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, and col 13) all of the 
steps in amended claim 2, both as an inventive concept and as computer 
program functions and steps to be performed, either implicitly or explicitly. He 
inherently teaches the use of price tables and tier/pricing (product) rules for both 
products and sub-products linked to financial transactions, and rules linked to 
price tables, identifying the correct rule for the transaction, and pricing the 
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transaction according to the tier/pricing (product) rules, all towards the logical end 
purpose of utilizing all of those steps for a billing method. See response to claim 



As to Claim 3 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, and 
col 13) "The method of Claim 1 ...display only information.", both as an inventive 
concept and as computer program functions to be performed with as many other pieces 
of identifying and descriptive information as would have been needed to effectively 
operate the system. It would have been obvious to one skilled in the art at the time of 
the invention to have utilized a display only option, as not all computer screens require 
either text or a response, and to have included all the steps described in this claim. See 
response to claim 1 . 

As to Claim 4 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) 
"The method of Claim 1 ....a price table.". , both as an inventive concept and as 
computer program functions to be performed. See response to claim 1 . 

As to Claim 5 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1....a pricing method." , both as an inventive concept and as computer program 
functions to be performed. See response to claim 1 . 

As to Claim 17 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1 ...for said product rule". , both as an inventive concept and as computer 
program functions to be performed. See response to claim 1. 



1. 
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As to Claim 18 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1.... product rules to a database." , both as an inventive concept and as computer 
program functions to be performed. See response to claim 1 . 

As to Claim 19 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1 ....a default product rule.", both as an inventive concept and as computer 
program functions to be performed. See response to claim 1 . 

As to Claim 20 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1.... price table contains prices.", both as an inventive concept and as computer 
program functions to be performed. See response to claim 1 . 

As to Claim 22 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 1, wherein said price table 
contains negative values", both as an inventive concept and as means for computer 
program functions to be performed. 

OFFICIAL NOTICE is taken that it would have been obvious for pricing tables to 
have contained negative values for the purpose of zeroing out a prior price entry by 
either multiplying it by a negative 1 or have the actual price be a negative number to be 
added to the prior entry in order to zero it out, to make the price table function properly. 
In view of Gottesmans' teaching, it would have been obvious to one skilled in the art at 
the time of the invention to integrate Gottesmans' invention and OFFICIAL NOTICE with 
the teachings of Petroutsos because the combination of the three would have provided 
a completed, improved, and operational financial transaction system that could have 
been used by financial service companies. Likewise, in light of Petroutsos' teaching, it 
would have been obvious to'one skilled in the art at the time of the invention to integrate 
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the teachings of Petroutsos and OFFICIAL NOTICE with those of Gottesman for the 
same reason. 



As to Claim 23 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "A data processing system.... said product rule and said 
price table.", both as an inventive concept and as means for computer program 
functions to be performed, but he does not specifically teach the detailed programmatic 
steps for these software functions, such as "mandatory and optional" attributes as such. 
Petroutsos teaches (see his book in general, but particularly Chapter 3 at least the 
sections "Arrays" through "Arrays of Arrays", and "If.. Then. ..End", and Chapter 11 at 
least the sections "Databases and Database Management Systems" through "The Data 
Control's Properties"), by example of one of several computer programming languages 
then available, how relatively logical, simple, and obvious it would have been for one 
skilled in the art at the time of the invention to create the programming steps necessary 
to translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. For such skilled programmers it 
would have been obvious in a financial transaction system containing price tables and 
product (component) rules for multiple products (components) and multiple prices to 
develop the computer logic and the means for the pricing and other calculations 
required and to employ specific names, identifiers, and references for the pricing and 
product (component) databases (tables) and their data fields, together with the 
programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed. It is inherent in such 
programs to always have both mandatory and optional attributes in their tables and 
rules. For example a table or field identifier is mandatory in order for the program to 
function properly, yet the number and type of fields and the individual rule descriptions 
and logic are discretionary. It would also be obvious to allow for the temporary disuse of 
one or more of those rules as an optional attribute, for a variety of operational reasons: 
possible temporary discontinuance of the product as one example, or a change in the 
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attributes of the product itself as another reason. In view of Gottesmans' teaching, it 
would have been obvious to one skilled in the art at the time of the invention to integrate 
Gottesmans' invention with the teachings of Petroutsos because the combination of the 
two would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies. Likewise, in light of 
Petroutsos 1 teaching, it would have been obvious to one skilled in the art at the time of 
the invention to integrate the teachings of Petroutsos with those of Gottesman for the 
same reason. See response to claim 1 . 

As to Claim 24 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 10, lines 55-67, 
and cols 11-13) "The data processing system.... means for billing.", both as an inventive 
concept and as means for computer program functions to be performed. See response 
to claim 1 . 

As to Claim 25 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The data processing system.... display only 
information.", both as an inventive concept and as means for computer program 
functions to be performed. See response to claims 1 and 3. 

As to Claim 26 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The data processing system of Claim 23.... said 
mandatory attributes.", both as an inventive concept and as means for computer 
program functions to be performed. See response to claim 1 . 

As to Claim 27 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 10, lines 55-67, 
and cols 11-13) "The data processing system of Claim 26.... said identifier.", both as an 
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inventive concept and as means for computer program functions to be performed. See 
response to claim 1 . 

As to Claim 28 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The data 
processing system.... rules to a database." , both as an inventive concept and as 
computer program functions to be performed. See response to claim 1. 

As to Claim 29 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) The data processing system of Claim 23.... a default 
product rule.", both as an inventive concept and as means for computer program 
functions to be performed. Whenever there are several choices of actions to be applied 
to a table of rules and one or more of the rules has no special action specified in the 
original design of the table, then it is obvious to one skilled in the art at the time of the 
invention to have provided the means for a default action to that rule, and consequently 
provide for that eventuality in the design of the program logic. See response to claim 1 . 

Rejection, 35 U.S.C. 103(a) 

4. Claims 6-16 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Gottesman et al (US 6,049,782 A) (hereinafter "Gottesman") and Petroutsos 
(Mastering Visual Basic 5), further in view of Carter (US 5,878,400) as noted below. 

As to Claim 6 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is flat fee.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed, but he does not teach the 
many specific variations of pricing , all of which are old and well known, nor the detailed 
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programmatic steps for these software functions. Petroutsos teaches (see his book in 
general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays of 
Arrays", and "If.. Then. ..End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, which are only a partial listing of the 
many common pricing types, some of which have been used for the past several 
millenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
flat fee pricing. OFFICIAL NOTICE is taken that one of the oldest and best known 
pricing types is the flat fee type, which has long been commonly used for services of all 
types, such as Doctors, gardeners, hairdressers, and bank services, etc., and that it 
would have been obvious to modify the teachings of Carter with this OFFICIAL 
NOTICE. In view of Gottesmans' teaching, it would have been obvious to one skilled in 
the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching and that of OFFICIAL 
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NOTICE, it would have been obvious to one skilled in the art at the time of the invention 
to integrate the teachings of Carter and OFFICIAL NOTICE and Petroutsos with those 
of Gottesman for the same reason. 

As to Claim 7 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is unit price.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed. 

OFFICIAL NOTICE is taken that one of the oldest and best known pricing types 
is the unit price type, which has long been commonly used for goods of all types, such 
as groceries, office supplies, clothes, and bank services, etc., and that it would have 
been obvious to modify the teachings of Carter with this OFFICIAL NOTICE. In view of 
Gottesmans' teaching, it would have been obvious to one skilled in the art at the time of 
the invention to employ the teachings of Gottesman to the teachings of Carter because 
the combination of the two would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching and 
that of OFFICIAL NOTICE, it would have been obvious to one skilled in the art at the 
time of the invention to integrate the teachings of Carter and OFFICIAL NOTICE with 
those of Gottesman for the same reason. See responses to claims 1 and 6. 

As to Claim 8 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is unit cost.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed. 

OFFICIAL NOTICE is taken that one of the oldest and best known pricing types 
is the unit cost type, which has long been commonly used for goods and services in 
special circumstances, such as for sales of goods or services which were in addition to 
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other sales being made at the same time to the same customer or as an special 
incentive or a promotional price, and that it would have been obvious to modify the 
teachings of Carter with this OFFICIAL NOTICE. In view of Gottesmans' teaching, it 
would have been obvious to one skilled in the art at the time of the invention to employ 
the teachings of Gottesman to the teachings of Carter because the combination of the 
two would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching and that of OFFICIAL 
NOTICE, it would have been obvious to one skilled in the art at the time of the invention 
to integrate the teachings of Carter and OFFICIAL NOTICE with those of Gottesman for 
the same reason. See responses to claims 1 and 6. 

As to Claim 9 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is volume discount.", both as 
an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
the many specific variations of pricing , all of which are old and well known, nor the 
detailed programmatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "If.. Then. ..End", and Chapter 1 1 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, including volume discount, which are 
only a partial listing of the many common pricing types, some of which have been used 
for the past several millenia. For such skilled programmers it would have been obvious 



# 
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in a financial transaction system containing price tables and product (component) rules 
for multiple products (components) and multiple prices and pricing types to develop the 
computer logic for the many commonly known and used different types of pricing 
methods required for the many products involved and the means for the pricing and 
other calculations required and to employ specific names, identifiers, and references for 
the pricing and product (component) databases (tables) and their data fields, together 
with the programmatic means to both create all of the logic and tables and to link them 
all together for the purpose and function intended to be performed, including specifically 
volume discount pricing. In view of Gottesmans' teaching, it would have been obvious 
to one skilled in the art at the time of the invention to employ the teachings of 
Gottesman to the teachings of Petroutsos as modified by Carter because the 
combination of the three would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching it 
would have been obvious to one skilled in the art at the time of the invention to integrate 
the teachings of Carter and Petroutsos with those of Gottesman for the same reason. 
See responses to claims 1 and 6. 

As to Claim 10 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 1 1-13) "The method of Claim 5. ...is tiering.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed, but he does not teach the 
many specific variations of pricing , all of which are old and well known, nor the detailed 
programmatic steps for these software functions. Petroutsos teaches (see his book in 
general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays of 
Arrays", and "If.. Then. ..End", and Chapter 1 1 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
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the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, including tiering, which are only a partial 
listing of the many common pricing types, some of which have been used for the past 
several millenia. For such skilled programmers it would have been obvious in a 
financial transaction system containing price tables and product (component) rules for 
multiple products (components) and multiple prices and pricing types to develop the 
computer logic for the many commonly known and used different types of pricing 
methods required for the many products involved and the means for the pricing and 
other calculations required and to employ specific names, identifiers, and references for 
the pricing and product (component) databases (tables) and their data fields, together 
with the programmatic means to both create all of the logic and tables and to link them 
all together for the purpose and function intended to be performed, including specifically 
tiering pricing. In view of Gottesmans' teaching, it would have been obvious to one 
skilled in the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Carter and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 

As to Claim 11 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is cost plus.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed, but he does not teach the 
many specific variations of pricing , all of which are old and well known, nor the detailed 
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programmatic steps for these software functions. Petroutsos teaches (see his book in 
general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays of 
Arrays", and "If.. Then. ..End", and Chapter 1 1 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, including cost plus, which are only a 
partial listing of the many common pricing types, some of which have been used for the 
past several millenia. For such skilled programmers it would have been obvious in a 
financial transaction system containing price tables and product (component) rules for 
multiple products (components) and multiple prices and pricing types to develop the 
computer logic for the many commonly known and used different types of pricing 
methods required for the many products involved and the means for the pricing and 
other calculations required and to employ specific names, identifiers, and references for 
the pricing and product (component) databases (tables) and their data fields, together 
with the programmatic means to both create all of the logic and tables and to link them 
all together for the purpose and function intended to be performed, including specifically 
cost plus pricing. In view of Gottesmans' teaching, it would have been obvious to one 
skilled in the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Carter and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 
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As to Claim 12 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is minimum revenue.", both 
as an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
the many specific variations of pricing , all of which are old and well known, nor the 
detailed programmatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "If.. Then. ..End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, some of which are only a partial listing 
of the many common pricing types, some of which have been used for the past several 
millenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
minimum revenue pricing. 

OFFICIAL NOTICE is taken that minimum revenue pricing is old and well 
known, and has long been commonly used for goods and services in special price 
calculation circumstances, such as whenever the proscribed calculation method 
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had yielded only a very small nominal value that may not have included overhead 
or transactional expenses and the management position had been taken that all 
such transactions would have had at least a preset minimum revenue as its 
charged price, and that it would have been obvious to modify the teachings of 
Carter with this OFFICIAL NOTICE. In view of Gottesmans' teaching, it would 
have been obvious to one skilled in the art at the time of the invention to employ 
the teachings of Gottesman to the teachings of Petroutsos as modified by Carter 
and OFFICIAL NOTICE because the combination of the four would have 
provided a completed, improved, and operational financial transaction system 
that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching and that of 
OFFICIAL NOTICE, it would have been obvious to one skilled in the art at the 
time of the invention to integrate the teachings of Carter and OFFICIAL NOTICE 
and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 

As to Claim 13 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5. ...is maximum revenue.", both 
as an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
the many specific variations of pricing , all of which are old and well known, nor the 
detailed programmatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "lf...Then...End", and Chapter 1 1 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
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computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, some of which are only a partial listing 
of the many common pricing types, some of which have been used for the past several 
milenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
maximum revenue pricing. 

OFFICIAL NOTICE is taken that maximum revenue pricing is old and well known, 
and has long been commonly used for goods and services in special price calculation 
circumstances, such as whenever the proscribed calculation method had yielded an 
unusually high value that may not have been competitive or not have appeared 
reasonable to the customer, and the management position had been taken that all such 
transactions will have had at most a preset maximum revenue as its charged price, and 
that it would have been obvious to modify the teachings of Carter with this OFFICIAL 
NOTICE. In view of Gottesmans' teaching, it would have been obvious to one skilled in 
the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter and OFFICIAL NOTICE because the 
combination of the FOUR would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching and 
that of OFFICIAL NOTICE, it would have been obvious to one skilled in the art at the 
time of the invention to integrate the teachings of Carter and OFFICIAL NOTICE and 
Petroutsos with those of Gottesman for the same reason. See responses to claims 1 
and 6. 
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As to Claim 14 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is markup of total price.", 
both as an inventive concept for pricing as commonly used in financial transactions and 
as means for computer pricing program functions to be performed, but he does not 
teach the many specific variations of pricing , all of which are old and well known, nor 
the detailed programmatic steps for these software functions. Petroutsos teaches (see 
his book in general, but particularly Chapter 3 at least the sections "Arrays" through 
"Arrays of Arrays", and "If.. Then. ..End", and Chapter 11 at least the sections 
"Databases and Database Management Systems" through "The Data Control's 
Properties"), by example of one of several computer programming languages then 
available, how relatively logical, simple, and obvious it would have been for one skilled 
in the art at the time of the invention to create the programming steps necessary to 
translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. Carter teaches (see at least 
Figure 7) approximately 25 different types of commonly used pricing types, some of 
which are only a partial listing of the many common pricing types, some of which have 
been used for the past several millenia. For such skilled programmers it would have 
been obvious in a financial transaction system containing price tables and product 
(component) rules for multiple products (components) and multiple prices and pricing 
types to develop the computer logic for the many commonly known and used different 
types of pricing methods required for the many products involved and the means for the 
pricing and other calculations required and to employ specific names, identifiers, and 
references for the pricing and product (component) databases (tables) and their data 
fields, together with the programmatic means to both create all of the logic and tables 
and to link them all together for the purpose and function intended to be performed, 
including specifically markup of total price pricing. 

OFFICIAL NOTICE is taken that markup of total price as a pricing method is old 
and well known, and has long been commonly used for goods and services in sales tax 
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calculations and in special price calculation circumstances, as one example such as 
whenever the proscribed calculation method became outdated due to a price increase 
not yet there reflected, which required that an additional markup be charged on top of 
the total price, and that it would have been obvious to modify the teachings of Carter 
with this OFFICIAL NOTICE. In view of Gottesmans' teaching, it would have been 
obvious to one skilled in the art at the time of the invention to employ the teachings of 
Gottesman to the teachings of Petroutsos as modified by Carter and OFFICIAL NOTICE 
because the combination of the four would have provided a completed, improved, and 
operational financial transaction system that could have been used by financial service 
companies, complete with a wide variety of pricing types. Likewise, in light of Carter's 
teaching and that of OFFICIAL NOTICE, it would have been obvious to one skilled in 
the art at the time of the invention to integrate the teachings of Carter and OFFICIAL 
NOTICE and Petroutsos with those of Gottesman for the same reason. See responses 
to claims 1 and 6. 

As to Claim 15 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is bundled pricing.", both as 
an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
the many specific variations of pricing , all of which are old and well known, nor the 
detailed programmatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "If.. Then. ..End", and Chapter 1 1 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
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different types of commonly used pricing types, some of which are only a partial listing 
of the many common pricing types, some of which have been used for the past several 
milenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
bundled pricing. 

OFFICIAL NOTICE is taken that one of the oldest and best known pricing types 
is the bundled pricing type, which has long been commonly used for goods as part of 
the normal pricing method, as one example the sale of new cars, wherein several 
pieces of optional equipment that have been individually priced at full retail were 
routinely included with the car at a discounted value (bundled pricing) when purchased 
all together with the car, and that it would have been obvious to modify the teachings of 
Carter with this OFFICIAL NOTICE. In view of Gottesmans' teaching, it would have 
been obvious to one skilled in the art at the time of the invention to employ the 
teachings of Gottesman to the teachings of Petroutsos as modified by Carter and 
OFFICIAL NOTICE because the combination of the four would have provided a 
completed, improved, and operational financial transaction system that could have been 
used by financial service companies, complete with a wide variety of pricing types. 
Likewise, in light of Carter's teaching and that of OFFICIAL NOTICE, it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Carter and OFFICIAL NOTICE and Petroutsos with those of Gottesman for the same 
reason. See responses to claims 1 and 6. 
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As to Claim 16 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 6, lines 25-67, col 7, lines 48-67, col 
8, col 9, col 10, and cols 11-13) "The method of Claim 5.... is Cross CAA Bundled 
Tiering.", which he describes as Relationship Pricing, both as an inventive concept for 
pricing as commonly used in financial transactions and as means for computer pricing 
program functions to be performed, and although he does teach tiering, he does not 
teach the many specific variations of pricing by name, all of which are old and well 
known, nor the detailed programmatic steps for these software functions. However, it is 
inherent in financial institution pricing to analyze customer accounts, both across their 
several accounts and across the accounts of all major customers, and to employ a wide 
variety of pricing methods to price their services, including bundling and tiering, 
especially in relationship pricing which is essentially bundled pricing by definition. 
Petroutsos teaches (see his book in general, but particularly Chapter 3 at least the 
sections "Arrays" through "Arrays of Arrays", and "If.. .Then. ..End", and Chapter 1 1 at 
least the sections "Databases and Database Management Systems" through The Data 
Control's Properties"), by example of one of several computer programming languages 
then available, how relatively logical, simple, and obvious it would have been for one 
skilled in the art at the time of the invention to create the programming steps necessary 
to translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. Carter teaches (see at least 
Figure 7) approximately 25 different types of commonly used pricing types , including 5 
which contain the word "customer", which are only a partial listing of the many common 
pricing types, some of which have been used for the past several milenia. For such 
skilled programmers it would have been obvious in a financial transaction system 
containing price tables and product (component) rules for multiple products 
(components) and multiple prices and pricing types to develop the computer logic for 
the many commonly known and used different types of pricing methods required for the 
many products involved and the means for the pricing and other calculations required 
and to employ specific names, identifiers, and references for the pricing and product 
(component) databases (tables) and their data fields, together with the programmatic 
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means to both create all of the logic and tables and to link them all together for the 
purpose and function intended to be performed, including specifically cross customer 
account analysis (CAA) bundled tiering pricing, which is inherent in and is relationship 
pricing. In view of Gottesmans' teaching, it would have been obvious to one skilled in 
the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching, it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Carter and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 

As to Claim 21 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 1 , wherein said price table 
contains costs.", both as an inventive concept for pricing as commonly used in financial 
transactions and as means for computer pricing program functions to be performed, but 
he does not teach the many specific variations of pricing , all of which are old and well 
known, nor the detailed programmatic steps for these software functions. Petroutsos 
teaches (see his book in general, but particularly Chapter 3 at least the sections 
"Arrays" through "Arrays of Arrays", and "If.. Then. ..End", and Chapter 1 1 at least the 
sections "Databases and Database Management Systems" through "The Data Control's 
Properties"), by example of one of several computer programming languages then 
available, how relatively logical, simple, and obvious it would have been for one skilled 
in the art at the time of the invention to create the programming steps necessary to 
translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. Carter teaches (see at least 
Figure 7) approximately 25 different types of commonly used pricing types, including 
base cost and one he terms "give it to them for cost", which are only a partial listing of 



Application/Control Number: 09/183,335 
Art Unit: 3628 



Page 24 



the many common pricing types, some of which have been used for the past several 
millenia. The at-cost prices also serve as cost information outside of the cost accounting 
system for any person who wishes to review it. For such skilled programmers it would 
have been obvious in a financial transaction system containing price tables and product 
(component) rules for multiple products (components) and multiple prices and pricing 
types to develop the computer logic for the many commonly known and used different 
types of pricing methods required for the many products involved and the means for the 
pricing and other calculations required and to employ specific names, identifiers, and 
references for the pricing and product (component) databases (tables) and their data 
fields, together with the programmatic means to both create all of the logic and tables 
and to link them all together for the purpose and function intended to be performed, 
including specifically product costs. In view of Gottesmans' teaching, it would have been 
obvious to one skilled in the art at the time of the invention to employ the teachings of 
Gottesman to the teachings of Petroutsos as modified by Carter because the 
combination of the three would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching it 
would have been obvious to one skilled in the art at the time of the invention to integrate 
the teachings of Carter and Petroutsos with those of Gottesman for the same reason. 
See responses to claims 1 and 6. 

5. The prior art of record, although not cited above, is considered pertinent to one 

or more of the Applicants 1 claimed inventions: 

US 4,855,908 to Skimoda et al, which teaches price table lookups. 

US 5,710,887 to Chelliah et al, which teaches pricing rules. 

Boris Beizer, Software Testing Techniques, International Thomson Computer Press, 
Boston, MA, 1990, which teaches the need to test software before implementation. 
Paul Carrubba, Principles of Banking, American Banking Association, 1994, which 
teaches that pricing is based upon account analysis. 
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6. Response to Applicant's Arguments 

As persons of scientific competence in the fields in which they work, examiners 
and administrative patent judges on the Board are responsible for making findings, 
informed by their scientific knowledge, as to the meaning of prior art references to 
persons of ordinary skill in the art and the motivation those references would provide to 
such persons. Absent legal error or contrary factual evidence, those findings can 
establish a prima facie case of obviousness. In this case, the appellants have not 
pointed to any legal error affecting the Board's obviousness analysis. Nor have they 
pointed to sufficient factual grounds, either in the record or in any judicially noticeable 
sources, to question the findings made by the examiner and the Board as to the 
teachings of the prior art and the motivation that the prior art references would give to a 
skilled artisan to make the claimed invention. We therefore sustain the Board's 
conclusion that the recited prior art references established a prima facie case of 
obviousness with respect to the appealed claims of the 774 and '654 applications. 

02-1 120, IN RE RICHARD A. BERG, ET AL. 

-1 160 On appeal from the United States Patent and Trademark Office, 

Board of Patent Appeals and Interferences. 
Decision affirmed. 
Opinion by Bryson, Circuit Judge. 

In response to applicant's argument that the examiner's conclusion of 
obviousness is based upon improper hindsight reasoning, it must be recognized that 
any judgment on obviousness is in a sense necessarily a reconstruction based upon 
hindsight reasoning. But so long as it takes into account only knowledge which was 
within the level of ordinary skill at the time the claimed invention was made, and does 
not include knowledge gleaned only from the applicant's disclosure, such a 
reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 
1971). 
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In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, 

In response to applicant's argument that there is nothing within the applied art 
teachings which would suggest the Examiner's proposed combination to arrive at the 
invention claimed in the present application, the test for obviousness is not whether the 
features of a secondary reference may be bodily incorporated into the structure of the 
primary reference; nor is it that the claimed invention must be expressly suggested in 
any one or all of the references. Rather, the test is what the combined teachings of the 
references would have suggested to those of ordinary skill in the art. See In re Keller, 
642 F.2d 41 3, 208 USPQ 871 (CCPA 1 981 ). It is the responsibility of the applicant to 
review all the referenced material regarding their teachings applicable to the application. 

Claim 1. In the specific reference originally cited, in col 8, on line 2 
Gottesman states "Transaction pricing...", and refers then to financial services 
products, which makes them " financial transactions " and products, and the logic 
that applies to the product rules, and all the rules, prices, and transactions are 
linked, stored in a database, accessed, identified, and prices are the result, and 
the broader reference cited "(see at least cols 1-14, ...") is the entire patent. 
Again in the original particular reference of col 7, lines 48-67 and col 8, lines 1- 
16, Gottesman discusses a pricing engine that uses pricing rules (logic) in tables, 
ie: pricing tables, that cover different rules, products, prices, and customer types, 
together with premiums/discounts that may apply, different types of financial 
transactions as specified in the tables, including the tier thev may include, and 
the rules include the specific fees that apply to different product components to 
be charged and billed, etc.. The attributes of these pricing rules and tables used 
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for financial transactions are the stated products, fees, and customer types etc. 
of Gottesman. Gottesman is not limited to a single account, but to all financial 
transactions of many accounts, some of which may not be termed relationship 
type accounts or transactions, as the relationship premiums/discounts are 
applied only after the standard pricing has already been calculated for each 
individual type of transaction, according to his pricing engine. If the Applicant will 
reread the particular reference cited he will be able to see the many small 
individual fees that go to make up the larger billing amounts , as Gottesman is not 
limited to only a larger universe of relationship banking prices. Petroutsos simply 
makes abundantly clear how common and simple it is to create computer 
programs and databases (eg: pricing rules and pricing tables) given any specific 
set of assumptions about them. Both Carter and foster disclose product rules and 
pricing tables and their application to financial transactions. Doktor discloses the 
implementation of a computerized database that contains and applies these rules 
and tables to financial transactions. Applicant argues that the pricing engine of 
Gottesman is only one of several portions of his pricing system, but the point is 
that it is at least one portion and it does perform the same function as the 
applicant is now claiming. 

Applicant's argument that Petroutsos own words render his teaches 
irrelevant is baseless, the last sentence says and is interpreted to say that "..the 
information in this chapter will (in fact) help you get up to speed quickly in 
database programming .." which will assist one in implementing the database 
system taught by Gottesman. 

But now we also have Carter, Foster, and Doktor for specific 
teachings on this matter, and the combination of the five is very clearly 
teaching everything claimed by the applicant; ie: claims 1-29. 



Claim 2. The particular reference in the Claim 1 response includes the attributes 
for and is the billing method and pricing method as described. It is also inherent in any 
elaborate and sophisticated set of pricing rules and tables for it to also translate into and 
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contain a billing and pricing method for the charges so calculated. One does not need to 
read the words that something is an " attribute or a method " to make it so, it is simply a 
matter of inherent definition. The Applicant's attention should not be limited to Claim 19 
of Gottesman when his entire patent has been cited as a reference. Applicant has failed 
to provide any evidence that the examiner's original rationale or findings were deficient. 

Claims 3 and 25. Assigning a name to one of many parts of a large set that 
requires subsequent future reference is a practice several millenniums old, and is not 
only obvious but inherent in the design of programs and databases. For the common 
practice as of the applicant's filing date regarding product/pricing rules and tables and 
display-only-information designed into software, it is inherent and obvious in software 
design to include a status field and pricing and billing information and display-only- 
information in order to make the rules and tables operative, and this reasoned argument 
was made in the original rejection. Applicant has failed to provide any evidence that the 
examiner's original rationale or findings were deficient. 

Claims 4 and 5. See response to claims 2, 3, and 25. 

Claims 13 and 15. A reasoned argument was stated in the original rejection for 
the use of obviousness and Official Notice, and the Applicant has not provided any 
credible evidence that the examiner's original rationale or findings were deficient. 

Claim16. See response immediately above. 

Claims 18 and 28. See response immediately above. 

Claims 19 and 29. See response immediately above. 



Claim 22. See response immediately above. 
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Claims 23-29. See responses to claims 1, 6-16, and 21 above, and prior 
responses to claims 23-29. 

Claims 6-16 and 21. As claim 1 remains rejected, Applicant's argument 
becomes mute. For the original reasons stated, each of these claims remain rejected. 



7. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 

§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

8. Note is taken by the examiner that should the applicant find objectionable any 
statements made herein by the examiner regarding inherency, implicitness, 
obviousness, or Official Notice, Applicant can make a proper challenge to those 
statements only by providing adequate information or argument so that on its face it 
creates a reasonable doubt regarding the circumstances justifying those statements: a 
simple response requesting a reference without doing so, or a response that fails to 
logically refute the basic assumptions underlying the justification, will result in an 
improper and failed challenge and those unchallenged statements will remain the record 
of the case. Applicants must seasonably challenge those statements in the first 
response following an Office Action. If an applicant fails to do so, his right to challenge 
them is waived. 



Response to Arguments 
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9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Richard Fults whose telephone number is 703-305- 
5416. The examiner can normally be reached on weekdays from 8:30 to 5:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hyung Sough, can be reached on (703)-305-0505. The fax phone number 
for the organization where this application or proceeding is assigned is 703-305-3597. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is 703-308- 



1113. 
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